Recent development of networking has created new applications for network communication devices which transmit/receive e-mail messages over the Internet or like network.
Some newly developed network communication devices can not only capture an image with a built-in scanner function, but also forward the captured image information to a computer or like apparatus connected to the network in the form of an attachment file of an e-mail message. Network facsimile machines have been developed too which incorporate a built-in print function and telephone function in addition to the scanner function.
Such a network facsimile machine is disclosed in, for example, Japanese Published Unexamined Patent Application 2001-274944 (Tokukai 2001-274944, published on Oct. 5, 2001). FIG. 17 is a schematic showing an arrangement of the machine. In that network facsimile machine, an e-mail message sent from a transmitting-end terminal 1 to a transmitting-end mail server machine 2 is transferred to a receiving-end mail server machine 4 via a network 3 using an SMTP (Simple Mail Transfer Protocol) or another predetermined mail transfer protocol. The e-mail message is then stored in the receiving-end mail server machine 4. A receiving-end terminal 5 periodically accesses the receiving-end mail server machine 4 using POP3 (Post Office Protocol 3) or another mail receiving protocol to retrieve the stored e-mail message.
Further, the network facsimile machine is adapted to delete the e-mail message received by the mail server machine 4 so that the e-mail message is not repeatedly transferred after the e-mail message is received and its attached image information is printed out as a received document.
A problem occurs under these circumstances where information is transmitted using an e-mail message as in the foregoing: unlike, for example, those cases when information is transmitted by a normal facsimile machine, the transmitting end has no means to determine whether the information is received normally or processed properly by the receiving end. Specifically, unlike normal facsimile machines performing real time communication with each other over a PSTN (Public Switched Telephone Network), since the receiving-end terminal 5 of the network facsimile machine is not always connected to the mail server machine 4, and the transmitting-end terminal 1 can forward a message to the mail server machine 2 anytime no matter whether the receiving-end terminal 5 can receive it at that time, the receiving-end terminal 5 may take time to actually receive a message, and the transmitting end cannot judge at the time of transmission whether the message is receive normally or processed properly as mentioned in the foregoing.
Therefore, conventionally, when there is a need to confirm safe delivery of the information transmitted from the network facsimile machine, the operator must inconveniently confirm by a telephone call. It is also a problem that e-mail communication loses one of its advantages over telephone communication that the parties involved do not need to talk in real time.
Accordingly, a conventional method technique addressing these shortcomings is defined by the MDN (Message Disposition Notification) method in RFC 2298 which provides a means of confirming safe delivery of an e-mail message whereby upon reception of an e-mail message, the receiving-end terminal sends a confirmation message back to the transmitting-end terminal.
“RFCs” (Requests For Comments) are official documents issued by IETF (Internet Engineering Task Force), an Internet-related technology standards organization. The documents define, for example, specifications and requirements of Internet protocols, such as IP (Internet Protocol), TCP (Transmission Control Protocol), HTTP (HyperText Transfer Protocol), and FTP (File Transfer Protocol), and various Internet-related technologies. They are numbered throughout like “RFC 2298” and publicly available.
Japanese Published Unexamined Patent Application 2001-309109 (Tokukai 2001-309109, published on Nov. 2, 2001) discloses an arrangement of a machine equipped with the MDN function where if an MDN request is sent without receiving a return message by e-mail from the receiving end within a certain period of time after the completion of the transmission, a delivery failure notice is printed out to notify the operator that no return message is sent back. The operator can thereby confirm whether the message has been normally transmitted to the receiving-end terminal.
To realize the MDN function, it is determined, with a preset waiting time as a reference, if the delivery failure notice is to be output according to whether an e-mail message is sent back or not within the waiting time after the information is transmitted. Therefore, the suitable waiting time may differ depending on, for example, whether the receiving-end terminal 5 is always connected to the mail server machine 4 as mentioned in the foregoing, the network environment (connection state to the server) including the transfer rate between the mail server machine 4 and the receiving-end terminal 5, and the settings of the receiving-end terminal 5 (as to response timing and other conditions).
Therefore, if the waiting time is set to a value suitable to the transmission destination with the slowest response speed so as to be compatible with all the transmission destinations, a situation is possible where the operator may not be notified quickly of an error which has occurred at the transmission destination (receiving end) with a fast response speed and take an undesirably long time before retransmitting the information. In contrast, if the waiting time is set to a value suitable to the transmission destination with the fastest response speed, a situation is possible where the receiving end has normally received the message, but may be so slow in the operation of sending a return message that it triggers timeout errors requesting repeated transmissions.